軟體工程的定義？

想來想去，AI 大家可能很了解，或多少有聽過，那軟體工程呢？
到底是啥？

Software engineering is programming integrated over time.
-- Titus Winters, What Is Software Engineering? [1] 。

直譯是「軟體工程是寫程式對時間的積分」。

如果沿著這個比喻，把橫軸看成時間，縱軸看成每單位時間投入在 programming 上的精力，那曲線下的面積(積分)，就可以理解成這段期間開發、修改與維護的總投入。

面積越大，所花費的精力就越多，反之亦然。

所以從這角度來看，在相同的使用期間、完成相同需求與品質的前提下，我們當然會希望這個面積越小越好。這代表隨著專案演進，我們能花比較少的精力去維持與開發。

因此可以理解：好的軟體工程，能幫助我們控制未來開發與維護的成本。

而當哪天突然發現，我只是要加一個功能，怎麼要改那麼多 code？怎麼又多出一堆 bug，還要下一堆 prompt？
那可能就可以開始懷疑，目前的專案是不是有些軟體工程上的問題了呢？

另外，軟體工程在 SEVOCAB[2] 上也有定義，用中文解釋就是，將有系統、有紀律、可量化的方法，應用於軟體的開發、運作與維護。

做個比較？

有沒有發現一件事情，上面提到的維護、有紀律、可量化，跟平常 coding 時「先把東西做出來」的關注點，好像不太一樣？

平常自己在 coding 時，多少能發現 AI 打造初步會動的版本的能力非常強。

e.g., 丟一張網頁截圖，它就能打造出看起來很像的東西；或者提個想法，AI 就能幫助我們快速做 POC。
但可能持續開發下去會發現，疑，怎麼越來越難改？或者逐漸改不動了？

或者以前在學校修課時，我們會希望，完成作業要求、拿好分數就好。
交出去之後，大概也不會再打開了吧。
這時候我們關心的，自然就是當下有沒有完成目標。

白話來說，沒有把後續維護納入考量時，coding 比較像是為了當下目標而活；有考慮到軟體工程時，我們則會為了未來的修改做準備與設計。

但這邊沒有對錯，從思考角度與期望的目標來看，就能發現區別：

1. 只考慮當下目標：
   • 通常可以直接往需求寫，很快看到結果。
   • 速度通常較快，只要交出能動的作業，或者驗證一個想法即可。
2. 也考慮後續開發與維護：
   • 可能需要多花一些時間，思考程式怎麼安排、修改後怎麼驗證。
   • 程式間具有邊界感，能讓未來的調整更容易，減少反覆修改或是找 bug 的成本。

但也不是設計越多，就越有軟體工程喔。
多出來的設計如果沒幫上忙，反而讓 code 更難理解，這就變成 over design 了。

所以什麼時候需要軟體工程？要學啥？

如果一個東西用完就丟，那就很不值得花大量時間去設計未來怎麼擴充。畢竟現在多花的精力，也要算進那個面積裡。

但如果是一個需要持續迭代的 app，e.g., 使用者可能越來越多、客戶有更多要求。那我們就得開始考慮，該怎麼為了之後的變動做一些比較靈活的設計。

看到這有沒有覺得 軟體工程 更像是一種抽象的思想與概念。只要做的事能幫助你在未來開發更容易 並且花的時間更少。我覺得這樣就多少具備一些軟體工程的能力了。

而平常聽到身為軟體工程師必看的 design patterns[3]、clean architecture[4]、clean code[5]…… 等等的書籍，就是一些幫助我們學習這些能力的通用心法與工具(?)

像 design patterns[3] 中就列了許多當出現哪種應用情境，就該使用哪種 pattern 的例子。

但我自己是覺得：軟體工程並沒有一套到哪裡都適用的最佳解，因為設計的好壞非常難以量化。畢竟程式都動得起來，測試都過了啊，你憑啥說要怎樣寫比較好

而這就是軟體工程有趣的地方，後續再繼續分享～

說不定在不久的將來，AI 也有很好的 scence 去設計架構，那就能完全被取代了呢 讚

reference:

[1] https://abseil.io/resources/swe-book/html/ch01.html?utm_source=chatgpt.com
[2] https://sebokwiki.org/wiki/An_Overview_of_the_SWEBOK_Guide
[3] https://refactoring.guru/design-patterns
[4] https://www.tenlong.com.tw/products/9789864342945
[5] https://www.tenlong.com.tw/products/9789862017050